前言

上一篇文章講到了 TCP 協定的三次握手的流程以及為什麼需要三次握手，今天就讓我們繼續看下去關於 TCP 協定的其他內容吧！

為什麼 TCP 是可靠、有序的？

本圖來源為RFC 9293

上圖是 TCP 的 header format，透過其中的某些資料能夠確認其正確性以及其順序

• Sequence Number（序號）：每個 TCP 都會有一個唯一的序號，接收方收到封包後可以透過序號以正確的順序重組資料，同時也透過序號確認是否有資料遺失。
• Checksum（校驗和）：透過校驗和，TCP 可以確認數據在傳輸過程中是否有出現錯誤，是由發送端進行計算，並由接收端進行驗證，如果對運算有興趣的人可以參考Checksum 計算，這裡就不多做介紹。

斷開連結之 TCP 四次握手（Four-way HandShake）

從上圖來看，主要可以分成以下四個流程：

1. client 端向 server 端發送 FIN 封包，表示 client 端已經完成了數據傳輸，請求關閉連線。
2. server 端收到 client 端的 FIN 封包後，回覆一個 ACK 封包，確認它已經收到了 A 的關閉請求，但此時 B 還可以繼續傳送未完成的數據。
3. 當 server 端的數據已經傳送完畢，準備要關閉連線時，發出 FIN 封包給 client 端，請求關閉連線。
4. 當 client 端收到 FIN 封包後，會回傳 ACK 封包給 server 端，此時 server 端在收到 ACK 封包後會進入 closed 狀態關閉連線，而 client 端在發出 ACK 封包後就進入等待關閉狀態，在時間到之後關閉連線。

什麼是 SYN 攻擊？

簡單看一下定義：

SYN 洪水攻擊 (半開放式攻擊) 是一種阻斷服務 (DDoS) 攻擊，旨在透過消耗所有可用的伺服器資源，使伺服器無法用於合法流量。透過重複傳送初始連線要求 (SYN) 封包，攻擊者能夠淹沒目標伺服器上所有可用的連接埠，使目標裝置緩慢回應或完全不回應合法流量。

也就是說透過從 IP 位址（通常是欺騙性的）快速發送大量 SYN 封包，這些 IP 位址不會對 server 端所產生的 SYN-ACK 產生回應，此時 sever 端會等待一段時間，因為也許會出現網路擁塞造成 ACK 封包延時或遺失，此時後續合法的請求將被拒絕，造成 server 無法正常運作。常見的應對技術如下：

1. Reducing SYN-RECEIVED Timer：減少 server 端等待 client 端回傳 ACK 封包的超時時間。
2. Increasing Backlog：增大系統用來暫存尚未完全建立的連線請求的隊列大小，使得一段時間內處理請求的數量提升，不過也要考慮到 server 的負載能力。
3. SYN Cache： SYN 封包後收到不立即分配完整的狀態分配，狀態分配會被延遲直到連線完全建立，避免在成功建立連線之前佔用系統資源。
4. SYN Cookies：不為 server 端收到 SYN 封包後連線分配任何狀態。而是將大部分的狀態編碼後保留在 SYN-ACK 中，直到收到回傳的 ACK 封包後根據內容重建連線狀態。

小結

今天介紹了除了常見的三次握手之外，關於 TCP 協定的一些內容，這個部分就先告一段落，明天會來介紹與 TCP 位於同一層的另一個協定：UDP ，那就明天見拉～

參考資料

RFC 9293
RFC 4987
SYN cookies
SYN 洪水攻擊